EP9. LLM 모델 평가의 개요와 기준

LLM 모델 평가는 학습 적합성(Cross-Entropy / Perplexity), 기능 정확성, 의미적 유사도의 세 축으로 구성되며, 도메인 특화 평가 데이터를 통한 PPL 측정이 실무 모델 선택의 핵심 기준입니다.

0. 사전 필수 용어 (선행지식)

본 주제 이해에 필요한 5개 핵심 용어를 정의합니다.

• LLM (Large Language Model): 대규모 텍스트 데이터로 학습된 언어 모델. 본 강의 전반에서 평가 대상으로 사용됩니다.
• NLP (Natural Language Processing): 자연어 처리. 인간의 언어를 컴퓨터가 처리하는 분야. 자연어는 같은 의미를 다양한 표현으로 나타낼 수 있어 정합 검사보다 의미론적 검사가 필요합니다.
• 토큰 (Token): LLM이 처리하는 최소 언어 단위. 단어, 서브워드, 문자 등 모델에 따라 다르게 분리됩니다.
• 확률 분포 (Probability Distribution): 모델이 다음 토큰으로 각 후보를 선택할 확률의 집합. Cross-Entropy와 Perplexity는 이 분포를 측정합니다.
• 신경망 (Neural Network): 데이터를 학습해 패턴을 추출하는 계층 구조. LLM은 Transformer 기반 신경망으로, 학습 데이터의 재현율이 품질의 정확성을 결정합니다.

📚 참고: NLP 기초는 HuggingFace NLP Course, 정보이론(Cross-Entropy·Entropy) 기초는 Stanford CS229 Notes 참조.

1. 주제 정의

LLM 모델 평가는 특정 언어 모델이 주어진 도메인의 데이터를 얼마나 잘 이해하고 예측하는지, 그리고 실제 과제에서 유용한 결과를 생성하는지를 체계적으로 측정하는 프로세스입니다. 평가 결과는 모델 선택, 에이전트 개발 범위, 서비스 품질에 직접적인 영향을 미칩니다.

핵심 아이디어: 일반 벤치마크 점수가 높더라도 도메인 특화 평가 데이터에서 PPL이 높으면 해당 모델은 우리 서비스에 적합하지 않습니다.

2. 풀려는 문제

실무에서 LLM 모델 평가가 필요한 주요 시나리오는 다음과 같습니다.

• 문제 1 — 모델 선택 비용: 수십 개의 후보 모델 중 실제 도메인에 적합한 모델을 체계적 기준 없이 선택하면 에이전트 개발 공수가 급증합니다.
• 문제 2 — 도메인 적합성 불일치: 범용 벤치마크에서 높은 점수를 기록한 모델이 특정 도메인(의료·법률·금융 등)에서는 PPL이 높게 나타나 실용성이 낮습니다.
• 문제 3 — 기능 정확성 측정의 어려움: LLM의 출력 다양성(MPL 다양성) 때문에 동일한 질문에도 답변 표현이 매번 달라져 단순 문자 일치 비교로는 정확성을 측정하기 어렵습니다.
• 문제 4 — 의미적 유사도 평가: 자연어는 같은 의미를 다르게 표현할 수 있어 정합 검사(exact match) 방식으로는 품질을 제대로 평가할 수 없습니다.

💡 실무 노하우: 모델 선택에 투자하는 비용(평가 데이터 구축·PPL 측정)이 에이전트 개발·운영 비용을 큰 폭으로 절감합니다. 도메인 특화 평가를 생략하고 범용 모델을 선택하면, 이후 프롬프트 엔지니어링·RAG·파인튜닝 등 추가 개발 부담이 선형 이상으로 증가합니다.

3. 핵심 개념·구조

LLM 평가는 다음 네 가지 요소로 구성됩니다.

• 학습 적합성 (Cross-Entropy / Perplexity): 모델이 학습된 상태가 우리 도메인 평가 데이터를 얼마나 잘 예측하는지 측정.
• 기능 정확성 (Functional Accuracy): 정해진 과제(예: 수식 계산, JSON 출력)에서 모델이 일관되고 정확한 답을 생성하는지 평가.
• 의미적 유사도 (Semantic Similarity): 자연어 특성상 동일한 의미를 다르게 표현하는 경우를 임베딩·LLM-as-Judge 등으로 평가.
• 기능성 평가 (Functionality): 모델 출력이 실제 사용자·서비스 맥락에서 유용한지 판단. 기준 정의가 가장 어렵고, 높은 기능성 점수는 외부 에이전트 구현 부담을 줄입니다.

LLM 모델 평가 구조
┌─────────────────────────────────────────────────────┐
│  LLM 모델 평가                                        │
│                                                     │
│  ┌─────────────────┐   ┌──────────────────────────┐ │
│  │ 학습 적합성       │   │ 기능 정확성               │ │
│  │ Cross-Entropy   │   │ (정해진 과제 비교)          │ │
│  │ → Perplexity    │   │ ├ 정규화 출력 강제          │ │
│  │   PPL 1 = 완벽  │   │ ├ 레거시 알고리즘(N-gram)  │ │
│  │   PPL 100 = 랜덤│   │ ├ 임베딩 유사도            │ │
│  └────────┬────────┘   │ └ 평가형 LLM 판정         │ │
│           │             └──────────────────────────┘ │
│  ┌────────┴──────────────────────────────────────┐  │
│  │ 의미적 유사도 & 기능성 평가                      │  │
│  │ 사람 판단 / LLM-as-Judge / 임베딩 비교          │  │
│  └───────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────┘

4. 구현 가이드 (Do It Yourself)

시작 전 (Before you begin)

선수 조건: - Python 3.10+ - pip install transformers torch datasets evaluate anthropic - HF_TOKEN 환경 변수 (HuggingFace 접근 토큰) - ANTHROPIC_API_KEY 환경 변수 (Anthropic API 사용 시)

소요 시간: 약 20~30분.

Step 1 — 도메인 평가 데이터셋 준비

목표: 우리 도메인에 특화된 텍스트 평가 데이터를 구성합니다.

from datasets import Dataset

# 도메인 특화 텍스트 예시 (의료 도메인)
domain_texts = [
    "환자의 혈압이 수축기 140mmHg를 초과하면 고혈압으로 진단합니다.",
    "당뇨병 환자의 공복 혈당은 126mg/dL 이상일 때 진단 기준을 충족합니다.",
    # ... 최소 100건 이상 권장
]
ds = Dataset.from_dict({"text": domain_texts})

⚠️ 주의: 평가 데이터는 모델의 원본 학습 데이터와 독립적으로 구축해야 합니다. 학습 데이터를 그대로 평가에 사용하면 PPL이 인위적으로 낮게 나와 의미 없는 결과를 얻습니다.

💡 실무 노하우: 도메인 골든셋(golden set)은 100~1,000건으로 시작합니다. 데이터가 많을수록 측정 신뢰도가 높아지지만, 100건으로도 모델 간 상대 비교에는 충분합니다.

📚 참고: HuggingFace datasets 라이브러리 공식 문서.

✅ 확인: len(ds) 가 목표 건수 이상임을 확인합니다.

Step 2 — Cross-Entropy & Perplexity 계산

목표: 도메인 데이터에 대한 모델의 예측 능력을 PPL로 수치화합니다.

import torch
import math
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "meta-llama/Llama-3-8B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id, torch_dtype=torch.float16, device_map="auto"
)
model.eval()

def compute_ppl(text: str) -> float:
    inputs = tokenizer(text, return_tensors="pt").to(model.device)
    with torch.no_grad():
        loss = model(**inputs, labels=inputs["input_ids"]).loss
    return math.exp(loss.item())

ppls = [compute_ppl(t) for t in domain_texts]
print(f"도메인 평균 PPL: {sum(ppls)/len(ppls):.2f}")

⚠️ 주의: PPL 값은 모델의 어휘(vocabulary) 크기와 단위(bit vs nat)에 따라 절대값이 달라집니다. 동일 단위·동일 데이터셋 기준으로 모델 간 상대 비교를 합니다.

💡 실무 노하우: evaluate.load("perplexity") (HuggingFace evaluate 라이브러리)를 사용하면 배치 처리·단위 통일이 자동으로 처리되어 직접 구현보다 재현성이 높습니다.

📚 참고: HuggingFace evaluate 공식 문서.

✅ 확인: 도메인 평균 PPL이 baseline 모델 대비 낮으면(또는 30 미만이면) 해당 모델이 우리 도메인에 적합합니다.

Step 3 — 기능 정확성 평가 (정규화 출력)

목표: 정해진 과제에서 일관된 정답을 생성하는지 평가합니다.

from anthropic import Anthropic

client = Anthropic()

def evaluate_functional_accuracy(question: str, expected: str) -> dict:
    resp = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=256,
        messages=[{
            "role": "user",
            "content": f"{question}\n\n반드시 JSON 형식으로만 답하세요: {{\"answer\": <값>}}"
        }],
    )
    raw = resp.content[0].text
    return {"raw": raw, "expected": expected}

result = evaluate_functional_accuracy("3 + 7 = ?", "10")
print(result)

⚠️ 주의: JSON 출력을 강제해도 일부 모델은 부연 설명을 추가합니다. API 수준의 structured output 기능(tool use / response_format)을 지원하는 모델을 우선 선택합니다.

💡 실무 노하우: Anthropic SDK의 tool use, OpenAI의 response_format={"type": "json_object"} 를 활용하면 JSON 파싱 실패율을 크게 낮출 수 있습니다 (2026-05 기준, 각 공식 문서).

📚 참고: Anthropic Tool Use 문서.

✅ 확인: JSON 파싱 성공률이 95% 이상이면 기능 정확성 평가 파이프라인이 안정적입니다.

Step 4 — 동작 확인 (테스트)

예상 출력:

도메인 평균 PPL: 12.4
JSON 파싱 성공률: 0.97
기능 정확성(정답률): 0.92

✅ 확인: 도메인 PPL < 30 (또는 baseline 대비 유의미하게 낮음) + 기능 정확성 > 0.85 를 동시에 달성하면 해당 모델을 다음 단계 후보로 진행합니다.

5. 적용 사례 (공신력 오픈소스 6가지)

다음 OSS들은 실제 LLM 평가 파이프라인에서 사용됩니다.

• EleutherAI lm-evaluation-harness (https://github.com/EleutherAI/lm-evaluation-harness) — PPL·MMLU·HellaSwag·ARC 표준 벤치마크 자동화. HuggingFace OpenLLM Leaderboard의 백엔드로 사용됩니다.
• HuggingFace Transformers (https://github.com/huggingface/transformers) — model.eval() + cross-entropy loss로 직접 PPL을 계산하는 표준 패턴을 제공합니다.
• HuggingFace evaluate (https://github.com/huggingface/evaluate) — evaluate.load("perplexity") 로 단위 통일·배치 처리를 포함한 표준 PPL 측정을 지원합니다.
• OpenAI Evals (https://github.com/openai/evals) — 평가형 LLM(LLM-as-Judge) 기반 채점 프레임워크. 다양한 평가 task 템플릿을 포함합니다.
• DeepEval (https://github.com/confident-ai/deepeval) — RAG 파이프라인·hallucination 메트릭·G-Eval 등 LLM 애플리케이션 평가에 특화된 라이브러리입니다.
• Anthropic Python SDK (https://github.com/anthropics/anthropic-sdk-python) — tool use 기반 structured output으로 기능 정확성 평가를 구현합니다.

📚 참고: 위 OSS들은 GitHub stars ≥ 5K 또는 Anthropic·OpenAI·HuggingFace 공식 SDK입니다.

6. 핵심 원리

Perplexity의 정보이론적 의미: 모델이 다음 토큰을 예측할 때 평균적으로 몇 개의 후보 사이에서 갈팡질팡하는지를 나타냅니다.

PPL = exp(Cross-Entropy)

• PPL = 1: 모델이 다음 토큰을 100% 확신으로 예측 (완벽한 학습 적합성)
• PPL = 100: 평균적으로 100개의 후보 중 하나를 랜덤하게 선택하는 수준

Cross-Entropy의 역할: 학습 데이터로 만들어진 신경망(학습 분포)과 평가 데이터(평가 분포)의 확률 분포가 얼마나 일치하는지를 측정합니다.

• Cross-Entropy ≈ 0: 두 분포가 거의 일치 (모델이 평가 데이터를 잘 예측)
• Cross-Entropy ≈ 2~3: 모델이 평가 데이터 예측에 어려움을 겪는 상태
• Cross-Entropy ≈ 4.6: 완전 랜덤 수준 (nat 단위 기준)

핵심 통찰: PPL은 모델의 학습 데이터가 우리 도메인 데이터 분포를 얼마나 잘 커버하는지를 측정합니다. 일반 벤치마크 PPL이 낮아도 우리 도메인 PPL이 높으면 실무에서 쓸모가 없습니다. 반대로 정치·과학 분야 모델에 의료 데이터를 넣으면 PPL이 높게 나타나는 것이 정상적인 현상입니다.

7. 변형·확장

• Sliding Window PPL: 긴 문서를 일정 크기의 window로 분할해 누적 평균 PPL을 계산합니다. 컨텍스트 길이 한계를 초과하는 문서 평가에 사용합니다.
• Token-level vs Sentence-level PPL: per-token loss를 그대로 사용하는 방식과 문장 단위로 합산 정규화하는 방식은 결과가 다릅니다. 비교 시 동일 방식 사용이 필수입니다.
• Batch Evaluation: vLLM·TGI(Text Generation Inference)를 활용해 대규모 평가 데이터의 throughput을 가속합니다.
• LLM-as-Judge: GPT-4o·Claude 등 강력한 모델을 심판으로 활용해 의미적 유사도와 기능성을 동시에 평가합니다(G-Eval, MT-Bench 패턴).

8. 다른 도구·접근과의 비교 (3-way)

💡 실무 노하우: 단일 메트릭으로 모델을 선택하지 않습니다. PPL → 기능 정확성 → LLM-as-Judge 순으로 단계적 필터링을 적용하면 비용과 정확도를 동시에 확보할 수 있습니다.

9. 한계·트레이드오프

1. PPL 단위 의존성: bit(log₂) vs nat(loge) 단위 혼동 시 모델 간 직접 비교가 불가합니다. 동일 라이브러리·동일 단위 사용을 강제하는 파이프라인이 필요합니다.
2. 어휘 크기 영향: 어휘 크기가 다른 모델(예: LLaMA 32K vs GPT 100K)의 PPL을 직접 비교하면 의미 없는 결과가 나옵니다. bits-per-character(BPC) 등 정규화 지표를 보완으로 사용합니다.
3. OOD(Out-of-Distribution) 평가 폭증: 평가 데이터가 학습 분포 밖에 있으면 PPL이 폭등하는데, 이것이 오히려 정상적인 신호입니다(모델이 해당 도메인을 모른다는 의미).
4. 기능성 ≠ 정확성: PPL이 낮아도 실무 추론(reasoning) 과제에서 잘못된 결과를 생성할 수 있습니다. LLM-as-Judge 보완이 필요합니다.
5. 평가 데이터 오염(Contamination): 평가 데이터가 모델의 학습 데이터에 포함되어 있으면 PPL이 인위적으로 낮게 나옵니다. 독립적으로 구축된 내부 평가셋이 필요합니다.

10. 권장 패턴 (2026-05 기준, Anthropic docs·HuggingFace docs)

• Structured Output 우선: Anthropic SDK의 tool use 또는 OpenAI의 response_format={"type": "json_object"} 를 활용해 기능 정확성 평가의 파싱 실패율을 최소화합니다.
• Multi-metric Evaluation: PPL + 기능 정확성 + LLM-as-Judge 3가지를 조합합니다. 단일 메트릭 의존은 잘못된 모델 선택으로 이어집니다.
• Domain Golden Set: 도메인 특화 평가 데이터 100~1,000건을 내부적으로 구축·관리합니다. 공개 벤치마크만으로는 도메인 적합성을 측정할 수 없습니다.
• 표준 벤치마크 참고 후 도메인 평가로 확정: HELM·HuggingFace OpenLLM Leaderboard 등 공개 벤치마크는 1차 후보 선별에만 사용하고, 최종 결정은 반드시 도메인 PPL 측정으로 확정합니다.
• 평가 파이프라인 자동화: lm-evaluation-harness 또는 DeepEval을 CI/CD에 통합해 모델 업데이트 시 자동으로 회귀 평가를 실행합니다.

11. 메타인지 자기평가

Step 1 — 현재 상태 점검

grep -rn "perplexity\|cross_entropy\|evaluate\|ppl" your_project/ | head -20

Step 2 — 적용 가능성 평가

다음 질문에 모두 "예"를 답할 수 있어야 평가 파이프라인을 신뢰할 수 있습니다.

• 도메인 특화 평가 데이터셋이 100건 이상 존재하는가?
• 평가 데이터가 모델 학습 데이터와 독립적으로 구축되었는가?
• PPL 계산 단위(bit vs nat)와 라이브러리를 비교 대상 모델 간 통일했는가?
• 기능 정확성 평가에서 MPL 다양성 보정 방법이 사전에 정의되어 있는가?
• baseline 모델(현재 사용 중인 모델)의 PPL을 측정해 비교 기준이 있는가?

Step 3 — 점진 적용 로드맵

1. HuggingFace evaluate.load("perplexity") 로 기존 모델 PPL 측정 → baseline 수립
2. 도메인 golden set 100건 구축 및 버전 관리(git)
3. 후보 모델 3개 이상을 동일 golden set으로 PPL 비교
4. PPL 상위 2개 모델에 대해 기능 정확성(JSON 출력 정답률) 측정
5. 최종 1개 모델을 LLM-as-Judge로 품질 검증 후 선정